Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/1152

Internet Message Format | 1994-08-27 | 10.9 KB

Date: Mon, 1 Aug 94 01:47 CDT
From: [e-mail] (Evan K. Langlois)
To: [e-mail]
Subject: Re: GEM List
Precedence: bulk

Note : I use cut-n-paste and macros for my quoting.  Using a left-margin
approach would take too much time and I'd need to do reformatting of the
quotes in some cases.  But, since, some people can't see my text separated
from the double-bar'd text (with CRs) I've switched to arrows.

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
If my guess is correct, then it is not a bug in AES.  Rather,
graf_dragbox and form_button use evnt_multi!  And since evnt_multi
... stuff deleted ... graf_mkstate, on the other hand, works just great.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

But the message isn't even sent until the button is back UP!  graf_mkstate
is a polling call.  My apps will use it ONCE after event_multi, and no
place else.

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Since evnt_multi win't sent repeated WM_TOPPED messages, I have to handle
everything after I get the first one, *plus I have to make sure the mouse
button it up before the next evnt_multi call*.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

How are you getting a WM_TOP message before the button is released?


vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
This works great.  The only problem is that while the button is down, the
operations of my library are trapped within itself, not getting back to
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I'm just gonna write my own dragbox routine and use rectangle events.
So, you could drag something with a right mouse button and select a menu
before you drop it, and have a window update itself. No modes at all.

Its gonna hit evnt_multi pretty often, so I'm gonna optimize it quite
a bit using a special binding.  However, unless the user has WINX or
MultiTOS or something, then drags from a background window with the
left button just won't work.  The library user decides what buttons
are used when, but in general, if you don't have anything else to do
with a button, it will work like the left button (and the more buttons
you have, the more you can do at once!).

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
AVOID scancodes it the app-defs file.  It's easy enough to tell the
difference between Backspace and Ctrl-H (or Return/Enter/Ctrl-M, etc...)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You don't HAVE to tell the difference!  If the scan-code doesn't match
anything in the app-defs list of scan-codes then just look at ascii
codes in the app-defs.   If you still don't find it, then it isn't
a hot-key, and if you do find it, then the attached string tells you
what operation to perform.

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Oh, and there's another problem with app-defs... if you don't have a TSR
to load it (of course translate it into something useful) and put it in
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Useful?  It is already in a useful form!  Why would you change it?  Let
the application writer use whatever form of lookup is best.  And what
makes you think you have to keep the whole file in memory?  The application
will load it, make whatever hash-tables or linked lists or whatever are
needed, and then free the ram!  Simple enough!

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
out whether it should use the default key or determine if the user's put
one in there to customise it just for that app.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

What?  If the information is available, use it, otherwise, not.  A TSR?
Do you realize how many problems you'll have with that?  A reboot to change
a program option?   I think not.  And with memory protection, any time
you use a pointer to something outside your program, you are opening the
way to lots of problems.


vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
any time a change is made because the size of the file would change
(although this isn't much of a big deal), plus it's harder to parce
(because if it's binary data, you don't have to parce at all!).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

And how should

*.Open.key : ^O

be represented in binary?  Overwriting an existing file is pretty easy,
although sharing modes could be a problem .. but multiple apps won't
have it open at once anyway.  Would you force everyone to search a linked
list with action/key pairs?  So, open would be 0x124 or something?  That
may be fine for you, but it may not suit everyone!  In fact, it will make
things HARDER for me.

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
This sounds very interesting.  I'll have to figure out Fselect.
One problem I have with modem I/O is that GEMDOS does not seem to provide
a way for me determine how many characters are there before using Fread.
As a result, I have to use Fread (or Bconin) repeatedly, reading one
character until Bconstat says there are no more characters.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Normal GEMDOS will read character by character but if you tell it to read
more than one character, it will block until an EOL character (CR).  To
stop this, MiNT can set the file handle to RAW mode with an Fcntl() call.
You can tell how many characters are waiting to be read with Finstat(),
although it may be easier to just read 2K and let Fread return with how
many characters were actually read, just like a file.  Fselect uses a
bitmap of file handles, so waiting on file 2 has the 2nd bit set.  The
docs are in the compendium, and in the mint man pages.  Use (1 << handle)
to get a value that can be or'd to your mask of handles. You can wait for
up to 32 file handles at once (the per application limit) with separate
read and write for each.

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
I have a couple or routines that read directly from the Iorec structure
and read the buffer directly.  It works VERY fast.  Would this interfere
with MultiTOS?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Kinda.  Not normally, since MiNT does use the IOREC structures, but it is
possible that a user will redirect modem IO to some other device, or may
be using a device driver with a different IOREC.  Reading from the Iorec
is definately bad practice.  These structures shouldn't be accesses by
the programmer.  You simply don't want to be messing with them while an
interrupt comes in, and you have no guarantee that you are accessing the
right structure since its so easy to redirect anything to another device!
Stay away from XBIOS calls, and only use IOREC if there is no other way
to get the information.  If MiNT is running, it has the calls you need!

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
How do I find out how many characters are there that I can read?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Finstat(), and the number you can write before blocking is Foutstat().
Pass the file handle, it returns a long.  Only available with MiNT.
Otherwise, there is no way to tell.

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
What is the file handle of the serial port?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

It's -2 to redirect the BIOS (or read write where the BIOS thinks the
AUX device is).  The GemDos one is 3, or stdaux.  That is the one you
should probably use since if the BIOS one gets redirected, this one
does to, but not the other way around.  The only problem is that this
does not point to the serial port on all version of TOS.  Any intelligent
library start-up code should check this and automatically do the proper
Fopen and such for you.

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Evan, you mention Fread having a raw-mode?  GEMDOS does not translate and
strip off cr's from cr/lf's.  And it does not wait for an EOL before
returning to the program.  It reads as many bytes as you tell it and then
returns.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This happens for raw-mode file handles, like disk access, but when reading
from the keyboard or modem, I think you'll find it reacts differently.
Try this :

  long cfh,mfh, n;
  char buffer[1024];

  mfh = Fopen ("AUX:",2);
  cfh = Fopen ("CON:",2);
  n = Fread (cfh,1024,buffer);
  Fwrite (mfh,n, buffer);

You will notice that nothing you type makes it to the modem until you
press return!

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
If I Fread x bytes from the serial port, does it wait until it gets x
bytes or does it return after it reads as many as it can?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I think it reads as many bytes as it can (when set to RAW mode).  I can't
be sure since I haven't changed my own terminal from BIOS to GEMDOS Raw
mode yet.  Maybe I'll do that soon.  I typed up about 8K on my lib though :-)
Either way, you can just use Finstat() and pass that to Fread().

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
For local echo, I would have both the main program and the threaded I/O
routine call the same function to deal with putting characters on the
screen.  I just have to be careful that they don't clash... I'd have the
main program wait until the thread was done.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Well, there are other benefits to the Pmsg() approach, since you can
send just about any info to the window, and have a true object.  You
could even load it from disk with the special Pexec() modes!  That would
be expandable and very safe, and trully object oriented!  And you can
sync the parts that need to be sync'd or let em run async.

Hmm .. you can just use a semaphore for that (MiNT's Psemaphore call).
It works well.  You need it whenever two functions can access the same
data in the same memory.  Especially if you might mess with a linked
list or something.  Having another process access the structure when
you are half-linked could be nasty, but if you just use your own variable,
then you could also have similar problems (although its not likely).
Psemaphore works even when the two processes don't share an address space.

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
I have posted descriptions of this before and in this message.  If
they're not clear, please ask questions.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I thought I did ask them!  Are you using the wind_update thing to handle
the mouse yourself (BEG_MSCTRL) ?  Or something else?